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ABSTRACT 


INTRODUCTION 


The NASA led Space Launch Initiative (SLI) 
program has established key requirements related to 
safety, reliability, launch availability and operations 
cost to be met by the next generation of reusable 
launch vehicles. Key to meeting these requirements 
will be an integrated vehicle health management 
(IVHM) system that includes sensors, harnesses, 
software, memory, and processors. Such a system 
must be integrated across all the vehicle subsystems 
and meet component, subsystem, and system 
requirements relative to fault detection, fault 
isolation, and false alarm rate. The purpose of this 
activity is to evolve techniques for defining critical 
flight engine system measurements^early within the 
definition of an engine health management system 
(EHMS). Two approaches, performance-based and 
failure mode-based, are integrated to provide a 
proposed set of measurements to be collected. This 
integrated approach is applied to MSFC’s MC-1 
engine. Early identification of measurements 
supports early identification of candidate sensor 
systems whose design and impacts to the engine 
components must be considered in engine design. 


NASA’s Space Launch Initiative (SLI) program has 
focused on the need for a safe, reliable, and low 
recurring cost reusable launch vehicle (RLV). It has 
as its goal at least an order of magnitude 
improvement in launch system safety, reliability and 
operations cost. Top-level program requirements 
enforce the critical nature of these goals and go far in 
stressing the need for a non-traditional design to 
reliability (and cost) approach. One of the key 
technologies at the system level is an engine health 
management system (EHMS) that is part of an 
overall integrated vehicle health management 
(IVHM) system. While IVHM is often seen as a 
panacea for any unreliability in the system, true 
design requirements for an IVHM system have been 
difficult to establish. The assumption here is that 
credible and quantifiable improvements in reliability 
are possible through the effective use of sensors, 
processors and algorithms. The challenge at hand is 
to balance the need for EHMS with the need for high 
performance, low weight, higher reliability, and 
lower cost - all critical issues to rocket engines. 
Careful definition of critical measurements; prudent 
selection of highly reliable sensors, harnesses, and 
processors; and inclusion of appropriate fusion logic 
are all necessary to build an effective rocket engine 
health monitoring system. 
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Figure 1: EHMS Vision 

Figure 1 presents the EHMS vision. Included in this 
are prognostic and diagnostic capabilities, advanced 
sensor systems and processes to ensure data 
collection, evaluation, prediction that use appropriate 
tools and metrics. 

The paper presents a two-pronged approach for 
identifying these measurements. The first approach is 
a performance-based modeling approach that defines 
the minimal set of measurements critical for engine 
data reduction and control. This approach identifies 
required pressure, temperature, speed and flow 
measurements. The second approach is a more 
traditional failure mode-based analysis of the engine 
that defines an extensive set of" measurements 
necessary for monitoring a large number of critical 
failure modes. This approach identifies the need to 
monitor measurements critical to engine control 
while also picking up the need to monitor other 
characteristics such as vibration and acoustics. This 
approach will yield a large number of sensors 
required to evaluate engine component health. The 
integration of these two approaches is a goal that will 
allow a convergence on an optimal set of 
measurements that can be used for engine control and 
engine failure mode monitoring. 

Both approaches identify parameters (and thus sensor 
systems) that are critical to the engine operation. 
Supporting these approaches must be a quantitative 
reliability evaluation process that is necessary to 
evaluate and rank the criticality of the measurements. 
This supports the decision to include or not. 1 A 
major part of the reliability evaluation is determining 
whether the sensor system would actually degrade the 
overall reliability of the engine system. This is 
possible through unreliable sensor, harness or 


processing software and through implementing a 
system that has a high incidence of generating false 
alarms (indicates a failure when none is present). 
The details of this reliability evaluation process are 
beyond the scope of this paper. Effective candidates 
for this are in place and also evolving. Such 
techniques include probabilistic design analysis 
(PDA) and probabilistic risk assessment (PRA). The 
former is oriented more to the physics of failure - 
less dependent upon condition reports and 
inspections but more dependent upon structural 
analysis data. PRA is more oriented to traditional 
roll-up of component and part estimates using fault 
trees or event trees and Boolean logic to calculate an 
overall system reliability. Good references for both 
techniques are shown in the reference section. 2 " 5 

BACKGROUND 

EHMS (and IVHM) are defined herein as the 
diagnostic, prognostic and maintenance management 
system consisting of sensors, harnesses, processors 
and algorithms. Included in the management system 
are capabilities to detect, isolate, and mitigate failures 
and maintenance issues. Independent algorithms can 
support detection and isolation for each sensor or can 
be used to fuse information to supplement detection 
and isolation information across the sensors. 
Algorithms may also refer to real-time models that 
are developed to assist in predicting the health of the 
system given the sensor readings are missing or 
suspect. The EHMS and IVHM are viewed as 
critical to fulfilling the need for improved safety, 
reliability and maintainability for engines and launch 
systems. 

Commercial EHMS systems such as those for aircraft 
provide the basis for belief in health management as 
highly effective in helping mitigate both critical and 
non-critical (maintenance) events. Other commercial 
systems are also successful in this regard 
(automobiles, commercial plant operations, etc.). 
The case is often made that rocket EHMS should 
show the same kind of benefit as aircraft EHMS. 
While this may be true in theory, commercial aircraft 
operations have large amounts of data, excellent 
understanding of the failure modes and life of the 
system components, and an ability to test to drive out 
failure modes, effects, and life limits. Also, aircraft 
systems are not as weight critical since they have 
much higher performance margins thap spacecraft. 
Other commercial systems, being ground-based, can 
build more robust components and provide even 
higher margins than aircraft. Technology for these 
systems may be at a greater readiness level. Rocket 


2 

American Institute of Aeronautics and Astronautics 


and aircraft propulsion systems vary considerably in 
several areas. These areas include operating 
environment; operating temperatures, pressures and 
thrust; ability to idle, taxi, and loiter aircraft engines 
and vehicles; use of cryogenic fuels on rockets; large 
performance margins on aircraft; relatively open 
access to support aircraft engine inspections; and, 
perhaps the major difference, a philosophy of use 
with aircraft that tolerates test and operational 
failures (and even loss of life). 

A rigorous and credible process must be in place to 
support the definition of the rocket EHMS since there 
is a perception, among many rocket engine designers 
that any EHMS, particularly the sensors and 
harnesses, are less reliable than the actual hardware. 
Thus, adding sensors is generally viewed as a bad 
thing. Such perceptions exist with good basis - this 
basis is the historical data collected during test and 
flight of launch vehicles. Early data (prior to ’95) 
from the space shuttle main engine (SSME) flights 
supports this perception - 2 of first 5 engine related 
aborts (4 on pad, 1 abort-to-orbit) were sensor 
related. The only shuttle abort-to-orbit vehicle flight 
occurred due to a sensor failure. Also, 2 of first 7 
engine related scrubs and delays were sensor related. 
Also, 24 of the first 29 engine anomaly reports since 
STS-26R were due to sensors. Sensor-related 
anomalies still occur and, given the data, one can see 
where the negative perspective regarding sensors 
came from. Unsatisfactory Condition Reports 
(UCR’s) collected after test and flight consistently 
reflect sensor and harness problems^ The perception 
is that extra software, sensors, fusion algorithms 
might only add to these totals relative to scrubs, 
delays, anomalies and UCR’s. 

In the reliability analysis of the EHMS candidates 
several factors have to be considered. These include 
the feasibility of detecting the failure mode, the 
ability to isolate it, whether the failure can be 
mitigated, and how fast the failure occurs. Other 
factors include the availability of appropriate sensors 
and the technology readiness levels of candidate 
sensor systems. False alarms in systems where 
mitigation capability is limited makes it a major 
concern. A logic to stop false alarms (data fusion, 
modeling, redundant sensors) also must be in place. 

OBJECTIVE 

The objective of this activity is to put a rigorous 
process in place for more accurate definition of 
required EHMS measurements, first for test but also 
for flight. An example to illustrate this process will 
be provided. As much as possible, the goal is to seek 


a quantifiable “closed form” solution. This is a goal, 
since, while the use of models to generate control and 
flow health measurements is fairly well established, 
the ability to model failure modes and effects and to 
quantify reliability and maintainability benefits is a 
developing technology. 

Reliability and maintainability design models need to 
be of high fidelity and in place for the design to 
effectively consider adding new sensors to the health 
management function. Reliability models have 
improved dramatically with the acceptance of 
probabilistic risk assessment (PRA) types of models. 
Models such as PRA will support the generation of 
quantitative metrics, which is important to decision 
support. Thus, any additional sensor (or removal of a 
sensor) would be based on an analysis that indicates 
convincingly that such a sensor should be 
added/removed. This analysis includes looking at all 
possible failures, times to failure, mitigation 
probabilities, and other information. There may be 
instances of failures that can be detected and isolated 
but not mitigated. If critical, EHMS will not be able 
to fully address this. If not critical, then sensors may 
be useful for maintenance purposes. Also, the 
probability of lowering reliability and increasing 
false alarms must be explored. False readings could 
be of two types: indicating failure when there is none, 
or indicating no failure when, in fact, such failure did 
occur. 

The following philosophy of design applies: 

• the goal is a minimal yet necessary suite of sensors 
and effective, sufficient coverage 

• due primarily to the concerns with sensor 
unreliability, measurements must “buy their way in” 
by showing their reliability and maintainability 
benefit; any sensors selected will need extensive 
testing in an applicable environment to be considered 
for inclusion. 

• the approach defined should be applicable to a 
complete vehicle and integrated MPS system 

• the approach must focus on measurements needed 
for control and flow monitoring with add-in high 
value measurements needed for failure 
mode/life/maintenance monitoring. 

Thus, to get started, the following information is 
needed and for the purpose of this paper it is assumed 
it to be in place: a good performance model to 

support control and health measurement definition; 
preliminary failure modes and effects definition; and 
good reliability (and maintainability) models 
generating credible quantitative metrics. 
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The approach described in this paper has been 
applied to the proposed engine health management 
system of the MC-1 rocket engine, as defined in the 
following section. 

MC-1 APPLICATION 

The MC-1 Engine (Figures 2 & 3) is a pump-fed, 
liquid rocket engine with fixed thrust. The engine 
was designed for the Low Cost Technology Project, 
and for the X-34 vehicle. The engine burns a mixture 
of RP-1 hydrocarbon fuel and liquid oxygen 
propellants, in a gas generator power cycle. 
Propellants are tapped from the engine propellant 
lines, and are burned as a fuel-rich mixture in a gas 
generator, to power a turbine, which rotates an in-line 
turbopump assembly. Turbine exhaust gas is routed 
overboard via a turbine exhaust duct routed along 
side the engine nozzle. The chamber/nozzle is built 
as one piece with ablative liner and composite 
overwrap. The engine operates at one rated power 
level, nominally 60,000 lbf at vacuum conditions for 
the 15:1 area ratio nozzle configuration, and slightly 
higher for the 30:1 nozzle. 



Figure 2: MC-1 Engine 


Thrust and mixture ratio are open-loop controlled by 
setting fixed orifices in the engine propellant lines 
during engine calibration testing. Therefore, 
variations in engine propellant inlet conditions cause 
engine performance variations. An electronic 
controller, external to the engine, issues electrical 
commands for engine start and shutdown. Engine 
start includes helium spin-up of the turbopump 
assembly, hypergolic ignition of the main injector, 
and pyrotechnic device ignition of the gas generator. 
The engine is capable of reuse, and is designed with 
line replaceable units (LRU). 


The engine is configurable for vertical operation, 
typical of booster application, or for horizontal 
application as used on the air launched X-34 vehicle. 
The engine actuator attach ring includes mounting 
locations for thrust vector control actuators as 
required for X-34. 

PERFORMANCE-BASED MODELING 
APPROACH 

The first method for selecting measurements is a 
performance-based modeling approach. This 
approach focuses on defining the minimum set of 
conventional measurements necessary for identifying 
shifts within component hardware used in an engine 
system diagnostic model. The output of this 
approach identifies both an optimal and redundant set 
of pressures, temperatures, speeds and flow 
measurements for evaluating engine component 
health and identifying failures. The two primary 
tools needed to support this sensor selection study are 
the ROCETS MC-1 mainstage engine design model 
and the Generalized Data Reduction (GDR) model. 6 
The engine design model is a system level model that 
uses physical relationships to predict the various 
operating states of the engine. This physics-based 
system model solves for mass, momentum and 
energy throughout the engine. This model is used to 
generate the functional relationships between both 
selected hardware characteristics and physical 
measurements. 

The GDR model is a robust data integration model 
that is used for numerically computing selected 
engine hardware characteristics from a specified set 
of engine measurements. The GDR model uses the 
functional relationships as a basis for determining 
performance shift causality at the component level. 
The model employs a scheme for determining the 
optimal set of sensors, as well as determining if the 
selected sensors can numerically solve for the desired 
set of hardware parameters. This GDR model was 
developed and utilized along with the design model 
to support test data reduction. Experienced engineers 
selected the initial sensors for the MC-1 engine, 
based upon acquiring the data necessary to evaluate 
the individual components. The GDR model was 
developed to provide a systematic approach for 
identifying the value of each of these conventional 
measurements on the health of the engine hardware. 
This procedure provides system-modeling engineers 
a tool for selecting engine measurements to support 
diagnostic modeling. 
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The following section will outline the process and the 
results from a detailed sensor selection study 
performed on the MC-1 engine. 7 The study was 
based on a premise of starting with a clean sheet wish 
list of desired hardware characteristics and a set of 
potential test measurements. The results of this 
sensor selection process is a list of sensors that can 
accurately solve for the final set of hardware 
parameters. 



Influences 
derived from MC-1 
Design Model 



M 


Simulated Data 
generated from MC-1 
Prediction Model 



Evaluate recovery of Hardware Parameters 
based on Selected Sensors 


ability to successfully recover predetermined 
numerical adjustments. 

The process for identifying the minimum and best set 
of diagnostic measurements is shown in figure 3. 
The process begins with identifying both a candidate 
set of hardware parameters and physical sensors. For 
the MC-1 engine, there are 32 potential candidate 
measurements that were selected, and 22 desired 
candidate hardware parameters to be solved. 



Figure 4: MC-1 Engine Candidate Sensor List 


Figure 3: Process for Diagnostic Sensor Selection 

A procedure was developed in the GDR model that 
selects hardware parameters and test measurements 
to be used within the reduction process based upon 
examining the condition number of a performance 
model influence matrix. Predicted hardware 
characteristics are recovered from the solution of a 
quadratic programming problem. Computational 
tests indicate that the GDR modeling procedure 
generates a consistent set of hardware adjustments, 
thus providing an accurate tool for supporting test 
data reduction. The subset selection process 
employed within GDR provides a method of 
identifying appropriate combinations of hardware 
parameters and internal measurement variables that 
limit the solution error bound. The Lz condition 
number of the hardware Jacobian, provides a measure 
of the computational limits of solution accuracy 
separate from model and measurement uncertainty 
effects. The automated parameter subset selection is 
applied primarily to eliminate measurements and 
stabilize ill-conditioned underdetermined systems. 
This method appears to effectively isolate and 
eliminate measurement redundancy and scaling 
problems. The criteria for evaluating and eliminating 
the hardware parameters is based primarily on the 


Note: Figure 4 above reflects a measurement labeling 
format common to rocket engine development. For 
example, PTRPFV is the total pressure in the RP line 
upstream of the turbopump. This is a measurement 
that also could be an actual sensor. 

Figure 4 above shows a schematic of the MC-1 
engine with the 32 candidate measurements and the 4 
engine inlet measurements. The initial selections of 
these sensors are based on identifying pressures, 
temperatures, and flows at both the inlet and 
discharge of each main engine component. The 
selection of the candidate hardware parameters was 
based upon component failure modes, and hardware 
characteristics within the design model that are 
calibrated using test data. Each of these 22 hardware 
parameters was individual perturbed +/-10% within 
the design model. The corresponding responses in 
each of the 32 potential sensors were recorded. A 
total of 704 influence coefficients were generated and 
organized into a matrix. In addition, these influence 
coefficients were used in a predictive model that was 
constructed for generating simulated test data. Data 
was generated for all 32 measurements by 
individually adjusting each of the 22-hardware 
parameters +10%. This simulated data was generated 
assuming the measurements readings are pristine or 
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without any precision error. The GDR model 
requires the base states of these 54 parameters, the 
matrix, and the simulated test data. 

The first step in evaluating these hardware and 
physical parameters within the GDR model is to 
calibrate the numerical process to the design model. 
The same sets of parameters are numerically solved 
in both models to ensure the results are identical. 
Within this first step, the GDR model yields the same 
set of test measurements as derived by engineers, 
with identical numerical results. 

The second step is to determine whether all of the 
hardware parameters can be numerically recovered 
based on the optimized selected set of sensors from 
the 32 candidate measurements. The purpose of this 
step is to ensure that all the desired hardware 
parameters can be accurately computed. 



Hardware 


% Recovery of 


Parameters 

Descriptions 

HdM^Parm. 



Discharge Coefficients 


1 

CDGGKI 

GG Fuel Injector Cd 

10.02% 

2 

CDGGCH 

GG Oxid Injector Cd 

10.04% 

3 

CDKJNJ 

MCC Fuel Injector Cd 

10.00% 

4 

CDOtNJ 

MCC Oxid Injector Cd 

10.00% 

5 

CDGGNZ 

GG Exhaust Duct Orifice Cd 

10.00% 

6 

XMGGKO 

GG Fuel Orifice Cd Mult 

9.99% 

7 

XMGGOO 

GG Oxid Orifice Cd Mult 

9.99% 

8 

XMHHCKO 


0.00% 

9 

KMMCOO 


0.00% 



Chamber/Nozzle Parameters 


10 

CDNOZL 

Nozzle Cd 

10.00% 

11 

ECSMMCHB 

MCC C* Efficiency Mutt 

10.00% 



Turbomachinery Parameters 


12 

PSIMKPMP 

Fuel Pump Head Coefficient Miift 

10.00% 

13 

14 

PSIMOPMP 

Oxid Pump Head Coefficient Mult 

10.00% 
ft mw 


i i miiuu mi 



15 

TRQMOPMP 


0.00% 

16 

ETAMHTGT 

Turbine Efficiency Mult 

9.99% 

17 

FRIG FACT 


0.00% 



Resistances/Others 


18 

RKFL1 

Fuel Pump Inlet Line Resis 

10.01% 

19 

RCALMF 

Main Fuel Line Resis 

10.00% 

20 

RCALMO 

Main Oxid Line Resis 

10.00% 

21 

ROLN1 

Main Oxid Inlet Dome Resis 

10.00% 

22 

QDOTVL1 8 

Heat Xfer (GG Lox Flow) 

9.98% 


Table 1 : Evaluation of the 22 Candidate Hardware 
Parameters 


Note: Table 1 reflects a hardware characteristics 
labeling convention common to rocket engine 
development. For example, CDGGKI is the derived 
discharge coefficient for the gas generator fuel 
injector. 

Table 1 shows the GDR numerical solution using the 
simulated test data for each individual hardware 
parameter. Of the desired 22 hardware parameters, 
17 successfully recovered the perturbed 10%, and 5 
were unable to be numerically recovered regardless 


of the selection of sensors. The slight difference in 
numerical values is attributed to the solution error. 
Each of these 5 hardware parameters is confounded 
with other hardware characteristics that were 
successfully solved. These 5 hardware parameters 
were eliminated from further sensor selection studies. 
In addition, a set of 17 sensors with the highest 
ranking was identified from the GDR automated 
sensor subset selection process. Table 2 below 
provides a summary of these 17 sensors. The 4 flow 
measurements highlighted represent new 
measurements selected that were not available during 
MC-1 testing. 



Fuel System 


Oxidizer System 

Bank 

Desciipfians 

Rank 

Bsscriplions 

15 

FueLPumpJnleLP 

1 

LOX_Pump_ds_P 

13 

FueLPump ds_P 

11 

GGOVJnlet.Flow 

3 

GGFVJnlet_Flow 

14 

GG_LOX_inlet_P 

8 

GG_Fuel_inlet_P 

17 

GG_LOXJnlet_T 

9 

FueLManifold_P 

16 

LOX_Orifice_ds_P 

2 

Fuel_Manifold_Flow 

10 

LOX_Dome_P 



5 

Fuel_Manifold_Flow 


Turbine 


Engine System 

Rank 

PascrjpiQna 

Rank 

Descrrotions 

4 

Turbine_ds_P 

7| 

MCCPc 

12 

Speed 

6 1 

Eng_SL_Thrust 


Table 2; Optimized Subset Sensor Selection Results 

The third step involves manually forcing each of the 
32-candidate measurement, one at a time, to be 
included into the subset selection process. The 
purpose of this step is to determine whether or not, 
each of the individual candidate sensors could be 
added to 16 other sensors to accurately solve for the 
17 hardware characteristics. This approach is used to 
assess the usefulness of all the candidate 
measurements. The process identified that 8 of the 
32 candidate sensors produced unacceptably high 
condition numbers. These 8 sensors were 
individually confounded with the other sensors that 
would result with inaccuracies in solving for the 
hardware characteristics. 

Table 3 provides a list of the 8 sensors along with the 
ratio of the absolute condition number to a reference 
value of a desirable condition number. The 2 sensors 
highlighted were measurements available during MC- 
1 testing. This process also identified several sensors 
that were redundant to other candidate sensors. 

The fourth step involved manually forcing each of 
the 17 optimally selected sensors, one at a time, to be 
eliminated from the subset selection process. The 
purpose of this step is to determine whether alternate 
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sensors could be used in place of these 17 sensors. 
This step is used to determine the relative value and 
importance of each of these 17 optimal sensors. As 
before, this step will use both the condition number 
and accuracy for assessing these sensors. The results 
from step 3 and 4 have identified 24 of the 32 
candidate sensors as recommended measurements for 
the MC-1 engine test program. 



Condition # 

Descriptions 

Ratio 

Fuel System 


1 FueLPump_ds_T 

2.22 

2 GGFVJnletJT 

2.22 

3 GG_FuelJnleLT 

2.22 

4 FueLManifoIdJT 

2.22 

Oxidizer System 


5 LOX_Pump_ds„T 

1.54 

6 GGOVJnletJT 

1.54 

7 LOX_Orifice_ds_T 

1.54 

8 LOX_Dome_T 

1.54 


Table 3: Candidate Sensors that were Eliminated 


t 

Sensors 

PSVL00 

Descriptions 
Fuel System 
FueLPump_lnl*UP 

Assessment of each Sensor 
Critical (no redundancy) 

2 

PSVL01 

Fu*l_Pump_d*_P 

Critical (no redundancy) 

3 

PSVL08 

GGFV_mlet_P 

Redundant to PSVL09 

4 

WGGFV 

GGFVJnlet_Ftow 

Redundant to TTKTGI, TTHTGD 

S 

PSVL09 

GG Fuel Jnl*U> 

Redundant to PSVL06 

6 

PTVLOS 

FtMLManlfold.P 

Critical (no redundancy) 

7 

WMFV 

Fu«i w ManifoH_Ftow 

Redundant to WRPTOT 

8 

PSOXDS 

Oxidizer System 
LO X_Purn p_d*_P 

Redundant to PS VL 15 

9 

PSVL15 

GGOVJnt*t_P 

Redundant to PSOXDS 

10 

WGGOV 

GGOVJntet_Flow 

Redundant to TTHTGI, TTHTGD 

11 

PSVL18 

GGJ-OXJntoi-P 

Critical (no redundancy) 

12 

TTVL18 

GGJXMUnkCT 

Critical (no redundancy) 

13 

PSVL13 

LOX_Ortfk»_d«_P 

Critical (no redundancy) 

14 

PTVL14 

LOX_Oom«_P 

Critical (no redundancy) 

15 

WMOV 

Fuel_Manifold„Flow 

Redundant to WOXTOT 

16 

TTHTG1 

Turbine 
Turbin* Jnl*t_T 

Redundant to WGGFV, TTHTGD, SNSHFT 

17 

PTVL22 

Turt»ln*_d*_P 

Critical (no redundancy) 

18 

TTHTGD 

Turbln*_da_T 

Redundant to WGGOV, TTHTGI, SNSHFT 

19 

SNSHFT 

Sp**d 

Redundant to TTHTGI, TTHTGD 

20 

PTHTGJ 

Chamber 

GGJPc 

Redundant to WGGOV 

21 

PTMCHY 

MCC_Pc 

Critical (no radundancy) 

22 

WRPTOT 

Engine System 
EngJRP-1 JnletJFlow 

Redundant to WMFV 

23 

WOXTOT 

Eng_LOX_lnl*t_Flow 

Redundant to WMOV 

24 

FT15A 

Enp_SL_Thru*t 

Critical (no redundancy) 


Table 4: Recommended MC-1 Engine Sensor List 


Table 4 provides a list and assessment of these 24 
sensors. The 19 sensors highlighted on the left side 
of the table were sensors available during MC-1 
testing. This study confirmed that the test program 
had a very good set of measurements to support 
modeling engine hardware. The process identified 10 
sensors that are critical to the numerical process that 
if not available would impact the solution of the 17 


hardware parameters. The process also identified 14 
sensors that are redundant to each other. Having 
these redundant sensors is extremely important for 
sensor validation and for providing alternate paths for 
numerical solving for the hardware characteristics. 

All of the results for this performance-based 
modeling approach were generated from 51 GDR 
model runs. This process systematically identified 
key sensors to be measured within the MC-1 engine 
for identifying shifts in the hardware performance. A 
future step beyond the sensor selection process is to 
account for precision error estimates associated with 
these final 24 sensors. This can be accomplished by 
generating the simulated test data with various levels 
of random sensor noise. The results from this 
process were not included within this paper. This 
process will provide the necessary information to 
evaluate the impact of the measurement accuracy to 
the accuracy in generating engine hardware 
characteristics. The results will provide a basis for 
determining sensor accuracy requirements or to 
differentiate the value of redundant sensors. This 
information is necessary for down selecting to a final 
set of engine diagnostic sensors. 

Limitations to this approach should be noted. These 
include: 

• Coverage of non-power balance information such 
as vibration and plume composition are not included. 

• Real-time control is the focus - maintenance 
concerns not generally reflected. 

• There is a lack of characterization of certain failure 
modes and effects. 

FAILURE MODE-BASED ANALYSIS 
APPROACH EXAMPLE 
(TRADITIONAL) 

The failure mode approach is augmented early in 
design through the application of lessons learned, 
previous studies, and best practices. References exist 
looking at historical data on engines and launch 
vehicles that list the top failure mode concerns and 
their criticality. 8 For example, an historical list of 
tradition failure mode concerns may include external 
leakage from joints on the engine, excessive 
turbopump torque, internal leakage of valves, bolt 
torque failure, coolant passage leakage, turbine blade 
failure, loose electrical connectors, bearing damage, 
seal leakage, valve failure, and contaminated systems 
including hydraulics. External leakage is always 
ranked as an overriding concern for the historical 
engines studied. 
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This type of analysis serves to pre-identify 
technologies for application to engines such as 
optical temperature and flow sensors, data fusion and 
model algorithms, optical particle detection for wear- 
out indication, infrared and area leak detection, and 
others. A list must also be generated as more detail is 
collected on the actual design failure modes of 
concern relative to the hardware of interest. 
Characteristics of the engine such as engine cycle, 
type of fuel and oxidizer, materials selected, mission 
requirements, turnaround requirements, and 
turbopump characteristics will of course be critical in 
identifying failure modes and their criticality. From a 
merger of the historical list and the current design 
analysis comes the candidate set of measurements for 
the engine under design. Of course, a quantitative 
evaluation of the impact to the reliability of the 
engine system is critical for ranking the items on this 
list. 

The following example is a selected failure mode 
analysis associated with MSFC’s MC-1 engine. 
Focus is on special sensor requirements associated 
with high risk criticality- 1 (catastrophic failure) 
failure modes associated with non-control type 
measurements. 

By analyzing failure modes of the engine components 
while taking into account the probability of those 
failure modes as given from historical data, three 
different types of sensors would be selected to 
improve the reliability and safety of the MC-1 
engine. 

A Failure Mode analysis would begin by establishing 
functional dependencies of all major components 
across the engine. Functionality may be further 
decomposed by engine operating modes such as 
“Chill Down”, “Prestart”, “Start”, “Mainstage”, and 
“Shutdown”. Instrumentation including sensors, 
harnesses, and processing units as well as mechanical 
components such as the turbopump, valves, ducts, 
the combustion chamber, and nozzle would be 
included in the analysis. Failure modes effects and 
their causes would be defined at each of the 
component levels with a resulting effect at the engine 
system level. Diagnostic tests are then defined that 
are used to determine the occurrence of the failure 
modes. An example of a commercial off the shelf 
(COTS) tool to aid in performing this analysis would 
be eXpress by DSI 9 , which employs a diagnostic 
dependency model approach. 

From this analysis, a table may be developed that 
lists each failure mode, whether or not the failure can 
be detected, instrumentation used to detect it, and 


what kind of mitigation action if any can be taken. 
Many of the decisions about failure mode detection 
and mitigation are heavily dependent on engineering 
experience and professional judgment both at the 
component level and at the system level. 

From the above analysis it was determined that a 
sensor or array of sensors that will detect 
concentrations of oxidizer and hydrocarbon fuel 
across various components of the engine including 
valves and ducts would be necessary to detect fluid 
leaks during mainstage operation of the engine. The 
technical specifics of the sensors are yet to be defined 
but the end result would allow detection of leaks of 
oxidizer and fuel that could potentially lead to fire 
and or explosion especially where the engine is 
mounted in the closed compartment of a vehicle. 
Mitigation strategies might include shutting down the 
engine or purging the compartment with a non- 
combustible gas. 

A second sensor or array of sensors that will detect 
vibrations on the turbopump would be necessary to 
detect degradation or failure of internal rotating 
machinery components such as the bearings, turbine 
blisk, and the turbo shaft. Again the technical 
specifics of the sensor and associated algorithms and 
the actual location for these sensors are to be defined 
but the result would allow detection of off-balance 
turbine blisk due to blade breakage or loss, turbo 
shaft whorl, and possibly ball bearing wear or 
degradation. The effect of these types of failures 
would contribute to loss of turbine efficiency or 
possible catastrophic failure of the engine system due 
to foreign object debris (FOD) down stream of the 
turbopump. Mitigation strategy for the MC-1 would 
require engine shutdown. 

Finally, a third sensor that will monitor temperature 
of turbine blades to a high resolution with a small 
uncertainty would be necessary to monitor peak 
temperatures of either the hot gases moving across 
the turbine blade surfaces or the metal of the turbine 
blades themselves. Technical specifics of the sensor 
implementation are to be defined, but this type of 
monitoring would be able to detect when the strength 
modulus of the blade has been affected due to high 
temperatures. During flight, when a certain threshold 
temperature has been exceeded for a specific period 
of time blade failure can be predicted. Mitigation 
strategy in real-time would involve shutting the 
engine down. Since exposure to thermal stresses 
contribute to blade failures, another use for this type 
of sensor would be for the prediction of blade life 
from post mission analysis of blade by blade 
exposure to peak temperatures during start up, 
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mainstage, and shutdown phases of engine operation. 
Post flight analysis of this type might indicate the 
need for manual inspection and replacement of the 
component as a ground based mitigation strategy. 

The above example has identified three special sensor 
systems for use on the MC-1 engine consistent with a 
limited crit-1 failure mode analysis. There are 
limitations to this approach and these include: 

• failure modes/life concerns not generally well 
understood, especially early in program 

• behavior of the system operating in the environment 
not well characterized, especially in the presence of 
failure 

• limited test time to validate models 

• high failure rates on new technology, especially 
sensor systems 

• unreliability of sensors, harnesses, software; added 
probability of false alarms with more sensors; 
negative impact to component performance having 
additional sensors (espec. intrusive sensors); are all 
difficult to analyze 


INTEGRATED MODEL APPROACH 

The limitations listed for the two approaches 
described in the sections above hint at the advantages 
for combining them. The philosophy of minimizing 
sensors is countered by the need to mitigate, as much 



Figure 5: Overview of EHMS Definition Process 
as possible, critical failure modes. Likewise, the 
logic of identifying all possible sensors is countered 
by the need to minimize sensors (focus on building 
robust hardware and avoid using unreliable and false 
alarm-prone sensor systems). 


In order to do this, an integrated modeling approach 
(see figure 5) is necessary. As much as possible, 
validated flow models that can provide attributes of 
the system in the presence of failure are necessary to 
couple the two. Physics of flow information that is 
augmented by failure mode information, required 
control measurements and the overall effect on the 
system best supports the integration of EHMS on the 
engine hardware and software. Thus, in such a model 
environment, performance concerns would be 
effectively coupled with reliability concerns. This 
model integration is a goal for future programs. 

CONCLUSIONS 

The paper presents an evolving analytical approach 
for defining the sensor suite for an EHMS system. 
This approach couples failure mode analysis with a 
control measurement definition approach to generate 
a set of critical control measurements and high-value 
health monitoring measurements. These are forced to 
“buy their way in” through the use of quantifiable 
reliability metrics. From this set of measurements, a 
set of sensor systems can be proposed for inclusion 
on the engine and included in engine design. 

Current limitations on models and reliability analysis 
must be rectified to take the next step - the 
integration of performance and failure mode 
modeling. Only when this occurs, can full 
characterization of the failures in the engine system 
be modeled. 

REFERENCES 

1. Christenson, R., et al, “Comprehensive Design 

Reliability Activities for Aerospace 
Propulsion Systems”, NASA-TP-2000- 
209902, January, 2000. 

2. Kecegioglu, D., “Reliability Analysis of 

Mechanical Components and Systems”, 
Nuclear Engineering and Design, pgs 259- 
290, August, 1971. 

3. Science Applications International 

Corporation, “Probabilistic Risk Assessment 
of the Space Shuttle: A Study of the 
Potential of Losing the Vehicle during 
Nominal Operation”, Vol. 1, NASA-CR- 
197808, 1995. 

4. Townsend, J. and C.Smart, ”ReIiability/Risk 

Analysis Methods and Design Tools for 
Application in Space Programs”, AIAA98- 
5276, October, 1998. 

5. Townsend, J., et al., “Review of the 

Probabilistic Failure Analysis Methodology 


9 

American Institute of Aeronautics and Astronautics 












and Other Probabilistic Approaches for 
Application in Aerospace Structural 
Design”, NASA TP-3434, November, 1993. 

6. Santi, L., and J. Butas, “Generalized Data 

Reduction Strategy for Rocket Engine 
Applications”, AIAA JPC, July 2000. 

7. Ballard, Richard O. and Olive, Tim, 

“Development Status of the NASA MC-1 
(Fastrac) Engine, AIAA 2000-3898, 36 th 


AIAA/ASME/SAE/ASEE Joint Propulsion 
Conference and Exhibit, July 2000. 

8. Rocketdyne, “Reusable Rocket Engine 

Maintenance Study - Final Report”, NASA 
Contract NAS3-22652, January, 1982. 

9. eXpress, DSI International, Orange, CA 

92867 


10 

American Institute of Aeronautics and Astronautics 



